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Id.  Abstract 


k.FAA  Advisory  Circular  AC  25.  1309-1  provides  guidance  material  for  demonstrating 
compliance  with  the  requirements  of  Part  25  of  the  Federal  Aviation  Regulations  for 
"Mflight-essentialM)and'rMflight-criticaIH^avionics  systems.  This  advisory  circular 
outlines  the  use  of  quantitative  safety  analyses  which  may  include:  a)  Probability 
analysis;  b)  fault  tree  analysis;  c)  failure  modes  and  effects  analysis;  and  d)  other 
comparable  techniques  for  determining  compliance  with  the  requirements  of 
FAR  25.1309(b). 

The  objective  of  this  study  was  to  explore  and  demonstrate  the  integrated  application 
of  reliability,  failure  effects  and  system  simulator  methods  in  establishing  the 
airworthiness  of  light-critica^P^digital  flight  control  system  (DFCS) .  The 
emphasis  was  on  the  mutual  reinforcement  of  the  methods  in  demonstrating  the  system 

safety.  /  ~hntt  c  tr  A  r4ic  —'?uf’F*.-u<r:r 


It  was  concluded  from  this  study  that:  a)  The  integrated  approach  can  be  used  for  the 
validation  of "flight-essential"  ^and<wf  light-critical>,) digital  systems;  b)  the  quanti¬ 
tative  assessment  of  reliability  (system  failure  probability)  can  be  accurately  pre¬ 
dicted  at  less  than  (JxliT^by  the  use  of  both  the  fault  tree  analysis  and  the  analyti¬ 
cal  reliability  prediction  analysis;  c)  fault  tree  analysis  must  be  augmented  by 
failure  modes  and  effects  analysis  which  must  be  used  below  the  circuit  card  level 
because  of  the  complexities  of  the  lower  level  analysis;  and  cl)  system  nimulut  f cm 
(fault  insertion)  confirms  the  correct  implementation  of  the  fault  dctcctirn  and  fault 

-  th.  system  ty4^^— — -  ’  . - 

Integrated  Assurance  Assessment  Document  is  available  to  the  U.S.  public 

Failure  Modes  and  Effects  Analysis  through  the  National  Technical  Information 

Fault  Tree  Fault  Insertion  Service,  Springfield,  Virginia  22161 


Integrated  Assurance  Assessment 
Failure  Modes  and  Effects  Analysis 
Fault  Tree  Fault  Insertion 
Failure  Rates  RDFCS  Pallet 
Digital  Flight  Control  System 

If.  S.rvftly  Cllltif.  (.1  Olii  »0*Cl)  1  8.  Sf 


UNCLASSIFIED 


Form  DOT  F  1700.7  »-*» 


30.  Security 

UNCL 


Cfottif.  (of  fM*  pop*) 


j  UNCLASSIFIED 

Reproduction  of  completed  pogc  oylSerliod 


21.  No.  of  Rogoft  23.  Prico 


FOREWORD 

This  report  describes  an  assurance  assessment  of  a  representative  con¬ 
temporary  digital  flight  control  system  stressing  the  use  of  various 
methods  in  a  complementary  manner.  The  work  was  performed  between 
February  1,  1982,  and  Septembery^Q^  1982,  under  contract  number  NAS2- 

11179.  The  work  was  sponsored  and  directed  by  the  Federal  Aviation 
Administration  Technical  Center,  with  the  contract  administered  through 
the  National  Aeronautics  and  Space  Administration  -  Ames  Research  Center 
under  interagency  agreement  NAS  NMI  1052.51  (Task  Order  DOT-FAA-77WAI-738) 
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i.  introduction  amp  suwmr 


Under  the  FAA  Technical  Center’s  Digital  System  Program  (182-3*0-100), 
an  integrated  assurance  asse saaent  of  a  contemporary  digital  flight  control 
systea  was  performed.  The  assurance  methods  of  fault  tree  analysis, 
autoaated  reliability  prediction,  failure  node  and  effect  analysis,  and 
fault  insertion  were  applied  in  a  complementary  way  to  address  the  need  for 
a  workable  approach  to  confirming  the  airworthiness  of  a  critical  digital 
system.  The  resulting  assessment  satisfied  the  requirements  of  Mvisory 
Circular  25. 1309-1  (Ref.  1),  and  is  consistent  with  the  validation 
requirements  of  RTCA  Document  DO-178  (Ref.  2). 

The  digital  system  used  in  the  analysis  was  the  Redundant  Digital 
Flight  Control  System  (RDFCS)  procured  jointly  by  the  FAA  and  NASA -Ames 
Research  Center  in  1979.  The  RDFCS  facility  is  located  at  NASA-Ames  as  a 
central  part  of  the  Digital  Flight  Control  Systems  Verification  Laboratory, 
a  unique  facility  for  research  into  the  assurance  Issues  of  digital 
systems.  Voluae  II  of  this  report  describes  the  RDFCS  as  it  would  be  in  a 
production  configuration,  including  sensors  and  servos.  The  sensors  and 
servos  are  not  production-configuration  equipment,  and  in  fact,  they  are 
simulated  in  the  RDFCS. 

The  assessment  consisted  of  the  following  major  tasks: 

o  Application  of  fault  tree  analysis,  starting  at  the  highest 
system  functional  level,  prooeeding  to  the  hardware  circuit  card 
level,  and  to  the  module  level  for  the  processors. 

o  Development  of  a  representative  set  of  failure  rates  for  the  .  , 
relevant  hardware  items. 

o  Application  of  an  automated  reliability  prediction  program, 
CARSRA,  to  the  system  failure  modes  affecting  airworthiness. 

o  Application  of  failure  mode  and  effect  analysis  to  Integrated 
circuit  pin  faults  of  three  processor  modules. 

o  Definition  of  faults  to  be  inserted  in  the  RDFCS  to  determine  the 
effect  of  the  fault  when  analysis  was  not  feasible,  and  of  other 
faults  to  oonfirm  the  manual  analysis.  These  faults  were 
subsequently  inserted  and  the  effects  recorded. 

Among  the  conclusions  and  observations  resulting  from  this  study  are 

that: 
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o  The  integrated  approach  used  here  is  capable,  with  dil'gent 
application,  of  establishing  the  airworthiness  o*  a  Digital 
Flight  Control  System  (DFCS)  within  the  context  of  AC  25.1309-1. 
Specifically,  this  approach  addresses  those  system  aspects  shown 
in  Table  1,  including  freedom  from  single-point  failure  modes  and 
system  failure  probability. 

o  The  integrated  assurance  approach  used  in  this  study  should  be 
considered  for  use  in  validating  other  digital  systems,  including 
DFCS,  in  compliance  with  AC  25.1309-1. 

o  The  quantitative  assessment  of  system  failure  probability  by  two 
methods  (fault  tree  analysis  and  analytical  reliability  pre¬ 
diction)  offers  increased  assurance  that  the  system  meets  the 
quantitative  requirements  of  AC  25.1309-1.  For  a  flight-critical 
system,  this  requirement  is  that  the  system  failure  probability 
not  exceed  1  x  10"’  per  hour  of  flight  for  each  critical  function 
the  system  performs. 

o  Fault  insertion  confirms  that  the  fault  detection  capability  and 
the  fault  tolerance  capability  described  in  the  system  documen¬ 
tation  are  actually  implemented  in  the  system.  Since  the  fault 
tree  analysis  is  based  largely  on  the  system  response  to  faults 
as  described  in  the  system  docunentation,  the  fault  insertion 
confirms  that  the  fault  tree  analysis  correctly  reflects  the 
behavior  of  the  actual  system  in  the  presence  of  faults. 

o  The  fault  tree  analysis  generates  software  test  requirements  in 
terms  of  functions  which  the  software  must  perform.  These, 
in  turn,  provide  a  check  of  function  criticality  and  of  test 
requirements  generated  in  accordance  with  RTCA  Document  DO-178. 

o  Fault  tree  analysis  proved  unwieldy  below  the  circuit  card  level, 
because  at  lower  levels  many  more  functions  are  being  performed 
than  there  are  hardware  failure  modes.  Failure  mode  and  effect 
analysis  was  accomplished  successfully  at  the  Integrated  circuit 
pin  level. 

o  As  a  training  facility  and  a  (^configurable  Test  Bed,  the  RDFCS 
facility  has  significant  and  valuable  capabilities  for 
Investigating  assurance  issues  of  currently  definable  DFCS 
architectures.  It  also  has  potential  enhanced  capability  in 
certain  areas,  such  as  automated  Insertion  of  pin-level  faults, 
for  confirmation  of  analytically  determined  fsilure  effects. 

o  The  comparison  of  the  time  or  cost  required  for  the  integrated 
approach  reported  here  with  that  required  for  other  possible 
assurance  approaches  was  not  specifioally  addressed  in  this 
study.  However,  the  time  required  for  the  integrated  approach  is 
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expected  to  compare  favorably  with  that  for  other  approaches, 
assuming  the  same  depth  of  analysis.  The  cost  should  also 
compare  favorably,  provided  a  facility  suitable  for  fault 
insertion  is  available. 


2.  OBJECTIVES  AMD  SCOPE 


OBJECTIVES 

The  primary  objective  of  this  contract  was  to  explore  and  demonstrate 
the  integrated  application  of  reliability,  failure  effects,  and  system 
simulator  methods  in  establishing  the  airworthiness  of  a  flight-critical 
digital  flight  control  system.  The  emphasis  was  on  the  mutual 
reinforcement  of  the  methods,  with  results  oriented  toward  inclusion  in  an 
FAA  Data  Base. 

SCOPE 

The  scope  of  the  effort  was  primarily  limited  to  assessment  of  the 
RDFCS  in  the  automatic  landing  maneuver  under  Category  Ilia  conditions  as 
defined  in  AC  120-28C  (Ref.  3).  Application  of  methods  below  the  system 
level  was  on  a  selective  basis  and  focused  within  the  digital  portions  of 
the  system.  Installation-dependent  effects,  such  as  failure  of  RDFCS 
components  induced  by  failure  of  components  in  other  systems,  were  not 
considered. 
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3.  CONTRACT  TASK  SUMMARY 


SYSTEM  DESCRIPTION 

A  baseline  configuration  of  the  RDFCS  shall  be  defined,  and  a 
corresponding  analytical  description  shall  be  prepared  as  necessary  to 
perform  the  integrated  assessment.  This  description  may  include  existing 
doounentation  for  the  RDFCS,  and  as  necessary,  it  shall  include  additional 
components  (e.g.,  secondary  flight  control)  needed  to  reflect  a  realistic 
DFCS. 

FAULT  TREE  ANALYSIS 


A  fault  tree  analysis  beginning  at  the  system  level  is  required.  The 
analysis  shall  be  extended  the  integrated  circuit  pin  level  for  at  least 
three  digital  modules. 

FAILURE  RATES 


A  set  of  representative  failure  rates  for  the  components  and  parts  of 
the  RDFCS  shall  be  developed  as  necessary  to  evaluate  the  fault  tree  for 
failure  probability. 

FAULT  SIMULATION  CASES 


A  number  of  simulated  fault  conditions  shall  be  defined  for  insertion 
in  the  RDFCS  simulator.  These  faults  shall  be  for  two  purposes:  to 
confirm  the  assumptions  underlying  the  fault  tree  analysis,  and  to  resolve 
uncertainty  of  the  effect  of  the  fault  when  analysis  is  not  tractable. 

FLIGHT  CASE  TRANSITIONS 


A  go-around  flight  ease  shall  be  installed  on  the  RDFCS  simulator ,  and 
transition  capability  shall  be  installed  to  transition  the  airplane  from 
approach  to  landing  and  landing  to  go-around  flight  cases. 
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CARSRA  RELIABILITY  PROGRAM 


The  CARSRA  reliability  program  shall  be  applied  to  the  RDFCS.  The 
application  shall  be  made  in  such  a  way  as  to  be  instructive  for  future 
applications  of  CARSRA  to  other  system. 
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RDFCS 


The  RDFCS  is  described  in  considerable  detail  in  Volume  II  of  this 
report.  The  description  presented  here  summarizes  the  system  architecture. 
In  most  operational  modes,  the  system  is  fail  passive,  with  a  dual  channel 
configuration.  For  automatic  landings  under  Category  Ilia  conditions,  the 
system  can  be  brought  into  a  dual-dual  fail-operational,  fail-passive 
configuration.  The  classification  dual-dual  relates  primarily  to  the  four 
computer  channels  in  the  system.  Each  of  the  two  flight  control  computers 
(FCC)  has  two  channels  which  run  frame-synchronously,  with  each  channel 
driving  one  coil  of  a  dual-coil  servo  in  each  axis.  Any  indication  of 
disagreement  between  the  two  channels  in  an  FCC  causes  the  servo  connected 
to  that  FCC  to  be  disengaged  by  removing  hydraulic  pressure.  Figure  1 
summarizes  the  dual-dual  configuration. 

Monitoring  Configuration  and  Implementations 

Extensive  monitoring  is  employed  in  the  RDFCS  for  fault  detection. 
Coil  current  comparators  for  each  servo  provide  coverage  of  faults 
resulting  in  erroneous  commands  to  the  servo  coils.  They  also  provide 
coverage  for  broken  wire  faults  between  the  FCC  and  the  servo  or  failures 
of  the  coils  themselves.  These  monitors,  which  are  described  in  Volune  II, 
Sections  5. 1.1. 6. 2  through  5. 1.1. 6. 5,  are  made  more  effective  by  the 
insertion  of  opposing  5  ma  bias  currents.  The  bias  currents  permit  circuit 
integrity  to  be  monitored  even  when  the  FCC  is  not  commanding  the  servo  to 
a  new  position,  such  as  when  the  aircraft  is  flying  through  very  calm  air 
at  a  stable  attitude.  It  may  be  noted  that  this  type  of  monitoring  is 
equally  applicable  to  analog  and  digital  systems. 

Response  of  the  autopilot  servos  to  commands  from  the  servo  amplifiers 
is  monitored  by  modulator  piston  position  signals  fed  back  to  the  FCC  (Vol. 
II,  Sections  5. 1.1. 6. 3  through  5. 1.1.6. 5).  The  feedback  signals  are 
averaged  and  passed  through  a  high-pass  filter  to  get  a  modulator  rate  that 
is  compared  with  coil  current.  This  comparison  is  used  to  detect  jamming 
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of  th«  modulator  piston,  runaway  conditions,  or  loss  of  hydraulio  power. 
This  type  of  monitoring  also  can  be  applied  to  either  analog  or  digital 
systems. 

In  the  pitch-axis  servos,  modulator  piston  position  monitoring  is 
implemented  in  hardware.  In  the  other  two  axes,  it  is  implemented  in 
software.  Together,  the  eoil  current  monitoring  and  modulator  piston 

monitoring  detect  any  servo  fault  which  prevents  the  servo  froei  responding 
to  commands.  They  also  detect  any  fault  in  a  computer  channel  which 
prevents  that  channel  from  generating  a  reasonable  command  for  the  servos 
in  each  of  the  three  axes.  All  monitors  and  feedback  sensors  are  dual  to 
increase  reliability. 

Each  computer  channel  has  an  iteration  monitor  Implemented  in  hardware 
(Vol.  II,  Figures  5.1.2. 1.2  through  5. 1.2. 1.3).  This  monitor  observes  the 
state  of  a  discrete  software  variable  which  is  changed  at  the  end  of  each 
iteration  of  the  foreground  software.  Since  this  software  exeoutes  at  a  20 
Hz  rate,  the  result  is  a  10  Hz  square  wave.  Should  the  processor 
short-loop  or  hang  up,  the  10  Hz  wave  will  not  be  presented  and  the 
Iteration  monitor  will  withdraw  its  input  to  the  engage  logic  and  the  FCC 
will  disengage. 

Sensor  monitoring  is  primarily  accomplished  by  comparison  and  by 
validity  discretes  generated  by  the  sensors  (Vol.  II,  Sec.  5. 1.2.4  through 
5. 1.2.8).  There  is  no  one  place  that  sensor  monitoring  takes  place,  since 
all  four  computer  channels  incorporate  the  monitoring  function.  This 
ensures  that  the  circuitry  Involved  in  getting  the  sensor  signals  to  each 
channel  is  included  in  the  monitoring. 

The  gyro  and  accelerometer  discretes  are  generated  as  described  in 
Volume  II,  Sections  5.11  through  5.12.  The  accelerometers  are  tested  as 
described  in  Section  5.11  each  time  the  system  is  powered  up  with  the 
airplane  on  the  ground. 

The  ILS  receivers  are  checked  using  the  square  wave  test  of  Volume  II, 
Section  5. 1.2. 3. 1. 1.5.  This  test  checks  for  failure  of  the  localizer  and 
glldeslope  beam  deviation  inputs.  During  landing,  the  outputs  of  both 
receivers  are  compared,  with  reliance  on  the  self-monitoring  to  identify 
which  receiver  is  bad  if  the  signals  disagree.  The  comparison  monitoring 
is  used  to  check  wire  integrity  between  the  receiver  and  the  computer 
channels.  The  other  dual  sensors  are  comparison  monitored  in  the  same  way. 
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Even  though  each  channel  monitors  sensors  individually,  any  channel 
can  initiate  the  NO  DUAL  annunciation,  which  is  the  primary  indication  that 
the  system  is  not  fail-operational.  If  any  channel  detects  a  seoond 
failure  of  a  sensor  type,  it  will  cause  its  FCC  to  disengage,  but  the  other 
FCC  will  remain  engaged. 

Although  NO  DUAL  is  the  primary  warning  of  loss  of  one  sensor,  NO 
ALIGN  will  be  annunciated  if  the  course  signals  from  the  two  compass 
systems  do  not  agree. 

Other  monitoring  within  the  FCC  involves  comparison  of  active 
operating  modes.  If  the  two  channels  within  an  FCC  disagree  on  which  modes 
are  engaged,  and  the  disagreement  lasts  for  more  than  0.1  sec,  the  FCC  will 
disengage.  If  the  two  FCC's  disagree,  SPLIT  will  be  displayed  on  the 
Warning  Annunciator  Indicators.  This  monitoring,  together  with  the  sensor 
data  transfers,  will  detect  most  faults  of  the  cross-channel  data  transfer 
circuitry. 

SIMULATOR  DESCRIPTION 


The  RDFCS  simulator  is  comprised  primarily  of  the  RDFCS  pallet,  shown 
in  Figure  2,  and  a  PDP  11/60  computer.  The  RDFCS  pallet  includes  the 
Flight  Control  Computers  (FCC),  core  memory.  Modular  Digital  Interface 
Control  Unit  (MDICU),  Servo  Simulator  Panel  (SSP),  Discrete  Switch  Panel 
(DSP),  CAPS  Test  Adapters  (CTA),  and  Computer  Breakout  Panels.  The 
functions  of  these  items  are  described  in  the  remainder  of  this  section. 

PDP  11/60  Computer /Airplane  Model 

The  PDP  11/60  computer  hosts  a  discrete-state  model  of  the  airplane  in 
which  the  RDFCS  is  installed.  This  airplane  is  a  representative  wide-body 
transport,  and  the  model  coefficients  are  changed  according  to  flight  case 
being  simulated.  Each  flight  case,  then,  is  a  point  simulation  of  the 
airplane  in  a  particular  configuration  and  operating  in  a  specific  portion 
of  the  flight  envelope.  The  airplane  model  executes  at  a  50  Hz  rate. 

As  part  of  this  study,  a  go-around  case  was  added  to  the  library  of 
cases  available.  These  cases  are  described  and  discussed  in  Reference  t. 
The  go-around  case  is  characterized  as  follows: 
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Airplane  Weight 
Altitude 
Angle  of  Attack 
Indicated  Air  speed 
Flap  Deployment 
Center  of  Gravity 


314,500  lb 
35  ft 
10.91° 

168  kts 
22° 

25*  of  c 


Transition  capability  was  added  to  go  from  approach  conditions  to 
landing  conditions,  and  from  landing  to  the  new  go-around  case.  The 
transitions  involve  changing  the  model  coefficients  and  establishing  new 
trim  values.  The  transition  capability  has  been  installed  and  checked  out 
successfully. 


Nodular  Digital  Interface  Control  Unit 


The  Nodular  Digital  Interface  Control  Unit  (HDICU)  receives  the  output 
of  the  airplane  discrete-state  model  through  a  communication  link  with  the 
PDF  11/60  computer.  The  MDICU  converts  the  various  pieces  of  information 
into  the  form  needed  by  the  FCC's.  For  example,  roll  angle  and  piteh  angle 
are  converted  to  three-wire  AC  signals,  properly  scaled,  while  locallaer 
deviation  is  coded  in  ARINC  serial  digital  format.  The  HDICU  is  described 
more  fully  in  Reference  5. 

The  HDICU  incorporates  provisions  for  the  signal  for  the  No.  1  sensor 
of  each  type  to  be  ramped  up  or  down.  This  facility  is  accessed  by  means 
of  the  HP  2645A  terminal  physically  located  in  the  pallet. 


Eaoh  sensor  signal  going  from  the  HDICU  to  the  FCC's  oan  be 
interrupted  at  the  Computer  Breakout  Panels  by  removing  the  appropriate 
juaper  plug.  Every  FCC  back  connector  pin  is  routed  through  one  of  these 
plugs.  The  lower  portion  of  Figure  3  shows  the  rows  of  plugs  for  oonneotor 
PI  and  the  "A"  half  of  connector  P2.  Each  FCC  has  its  own  breakout  panel. 
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Figure  3.  CAPS  Test  Adapter  and  Computer  Breakout  Panel 
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Figure  3  also  shows  the  CAPS  Test  Adapter  (CTA)  for  one  of  the  FCCfs. 
The  upper  half  of  the  CTA  includes,  on  the  right-hand  side,  four  address 
and  four  data  windows.  An  address  can  be  loaded  in  each  address  window, 
and  the  corresponding  data  window  used  to  display  the  data  on  the  FCC  A- 
side  processor  bus  data  lines  every  time  the  address  appears  on  the  address 
lines.  The  CTA  also  has  other  capabilities,  such  as  providing  a  history  of 
the  last  16  bus  transfers  and  changing  the  contents  of  a  specific  anory 
location  within  the  FCC,  but  during  the  study  only  the  address  monitoring 
was  used.  Discrete  variables  representing  sensor  voter  status  were 
monitored  visually  via  the  data  windows.  Continuous  variables,  such  as 
inputs  to  the  servo  amplifiers,  were  monitored  by  using  the  analog  output 
posts  below  the  appropriate  data  window  to  drive  a  strip-chart  reoorder. 

The  lower  half  of  the  CTA  performs  the  same  functions  as  the 
upper  half,  but  for  the  B  side  of  the  FCC. 

Servo  Simulator  Panel 

The  servo  amplifier  outputs  from  the  FCC's  are  routed  to  the  Servo 
Simulator  Panel  (SSP),  shown  in  Figure  4.  The  SSP  simulates  the  dynamics 
of  the  autopilot  and  power  servos,  and  generates  the  required  feedback 
signals  such  as  modulator  piston  position.  The  SSP  has  circuits  which  can 
simulate  a  hardover  or  slowover  command  to  a  servo  coil.  It  can  also 
simulate  a  hardover  or  slowover  of  a  modulator  piston.  Including  the 
modulator  piston  position  feedback  signal  and  the  command  to  the  power 
servo.  All  of  these  apply  to  the  No.  1  servo  of  each  type. 

Discrete  Switch  Panel 

The  Discrete  Switch  Panel  (DSP),  Figure  5,  is  located  just  below  the 
SSP.  This  panel  provides  a  centralized  location  for  switches  suoh  as 
hydraulic  pressure  switches  and  autopilot  disconnect  switches.  The  panel 
also  includes  switches  that  oan  be  used  to  insert  sensor  validity  faults. 
These  faults  can  also  be  inserted  by  pulling  the  appropriate  jumper  plug  on 
the  FCC  Breakout  Panel. 


Figure  5.  Discrete  Switch  Panel 
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Core  Memory 

The  pallet  also  contains  core  memory  for  the  FCC's.  This  is  used  for 
both  data  and  program  memory  to  provide  flexibility  and  convenience  in 
using  the  pallet  to  simulate  other  airplanes  or  DFCS  architectures.  As 
used  in  an  airplane,  the  FCC’s  have  the-  flight  software  stored  in 
programmable  read-only  memory  (PROM)  and  use  random  access  memory  (RAM) 
chips  for  data  memory. 

Glare-Shield  Panel 

The  pallet  also  has  a  glare-shield  panel,  which  is  the  control  panel 
for  the  system  as  installed  in  an  airplane.  It  includes  the  engage  (bat 
handle)  switches,  mode  select  switches,  altitude  select  knob,  and  other 
controls.  The  pallet  also  has  a  single  ADI,  HSI,  radio  altitude  display, 
Mode  Indicator,  and  Warning  Annunciator  Indicator. 


5.  FAULT  TREE  ANALYSIS 


FAULT  TREE  ROLE  IM  IMTEORATED  AS3URAMCE 


The  integrated  assurance  assessment  of  the  RDFCS  begins  with  a  fault 
tree  analysis  of  the  system  function.  Referring  back  to  Table  1,  the  fault 
tree  analysis  has  several  functions.  The  first  funotion  is  to  assure  that 
no  system  component  has  any  failure  mode  which  can  result  in  system 
failure.  Most  of  the  components,  such  as  the  sensors  and  servos,  have  only 
a  few  failure  modes  which  can  be  observed  at  the  interfaces  with  the  rest 
of  the  system.  For  these  components,  the  fault  tree  analysis  provides 
assurance  that  no  failure  modes  can  cause  system  failure.  The  assurance  is 
obtained  by  reviewing  the  completed  tree  and  determining  that  system 
failure  can  only  occur  as  a  result  of  multiple  failures. 

In  general,  digital  modules  (and  therefore  digital  components)  oan 

have  a  substantial  number  of  different  failure  modes.  Ih  such  oases,  it 

becomes  quite  laborious  to  continue  the  fault  tree  development  to  a  level 

of  detail  sufficient  to  confirm  that  none  of  those  failure  modes  can  cause 

system  failure.  The  second  function  of  fault  tree  analysis  is  to  identify 
* 

which  digital  modules  are  involved  in  performing  critical  functions.  The 
task  of  assuring  that  no  single  module  level  failure  can  cause  system 
failure  is  performed  with  failure  mode  and  effect  analysis  (FMEA). 

A  major  benefit  of  fault  tree  analysis  is  that  it  focuses  on  the 
functions  performed  by  the  system  elements,  including  those  system  elements 
involved  in  detecting  faults  and  providing  appropriate  annunoiatlon  to  the 
flight  crew.  Consequently,  the  third  function  of  fault  tree  analysis  is  to 
confirm  the  adequacy  of  monitoring  (l.e.,  fault  detection  and  annunoiatlon) 
in  the  system. 

Fault  tree  analylsis  is  also  used  to  identify  specific  software 
functions  required  for  system  operation,  including  fault  monitoring 
implemented  in  software.  The  software  test  requirements  for  these 
functions  are  then  specifically  reviewed  to  oonfirm  that  these  requirements 
are  adequate.  This  fourth  function  of  fault  trees  is  discussed  more  fully 
and  illustrated  subsequently  as  the  tree  for  the  RDFCS  is  developed. 


The  fifth  function  of  fault  tree  analysis  is  to  provide  an  alternate 
means  of  computing  the  probability  of  system  failure.  This  provides  a 
check  of  the  probability  obtained  from  the  CARSRA  program  to  ensure  that 
the  CARSRA  input  does  not  have  errors  which  would  produce  a  false  low 
probability  of  system  failure. 

FAULT  TREE  DEVELOPMENT 

The  fault  tree  analysis  is  based  on  the  undesired  event  that  the 
airplane  has  an  unacceptable  deviation  from  the  desired  flight  profile 
during  the  last  150  feet  of  descent  while  executing  an  automatic  landing, 
as  shown  in  Figure  6.  This  portion  of  flight,  which  is  the  only  flight 
phase  during  which  the  RDFCS  performs  a  critical  function,  is  termed  the 
"crucial  flight  phase"  in  this  report.  Category  Ilia  conditions  are 
assumed,  so  that  the  human  pilot  cannot  complete  the  landing  using  visual 
cues  should  the  RDFCS  fail. 

The  analysis  begins  with  the  RDFCS  in  the  dual-dual  configuration.  It 
should  be  noted  that  this  configuration  is  available  only  after  the 
Instrument  Landing  System  (ILS)  push-button  has  been  used  to  select  the 
Approach/Land  (A/L)  mode  (Ref.  Vol.  II,  Section  4. 3. 6.1).  After  this 
switch  has  been  momentarily  depressed,  the  A/L  mode  is  transmitted  to  the 
FCC's  and  latched  in.  The  switch  is  no  longer  needed,  and  therefore  does 
not  enter  into  the  analysis. 

The  top  event  of  Figure  6  can  be  caused  by  any  of  three  conditions,  or 
subevents.  For  convenience,  these  can  be  referred  to  as  Level-2  events, 
with  the  top  event  considered  to  be  at  Level  1.  The  Level-2  events  are 
shown  as  the  middle  row  in  Figure  6.  The  first  of  these  is  that  the  system 
design  is  in  some  manner  deficient  for  the  environmental  conditions 
encountered.  This  includes  the  possibility  that  the  conditions  encountered 
are  outside  of  the  system  design  requirements;  it  also  includes  the 
possibility  that  the  control  laws  are  deficient  for  some  conditions  whioh 
may  be  expected.  This  possibility  is  outside  the  scope  of  this  project  and 
is  not  pursued  here.  References  6  and  7  address  this  subject.  In  parti¬ 
cular,  Section  3.3. 1.3  of  Reference  6  discusses  establishing  an  upper  bound 
on  the  probability  of  a  deficient  control  law  by  statistical  methods. 
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Figure  6.  Fault  Traa  Top  Laval 
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The  second  of  the  Level-2  events  occurs  if  the  airplane  enters  the 
crucial  phase  with  the  RDFCS  not  fail-operational,  and  then  a  component 
failure  occurs  which  prevents  the  system  from  completing  the  landing. 

The  third  of  the  Level-2  events  is  that  the  crucial  phase  is  entered 
with  a  fail-operational  RDFCS,  but  multiple  component  failures  occur  before 
the  end  of  the  phase,  and  these  failures  result  in  RDFCS  system  failure. 

The  second  of  the  Level-2  events,  that  the  crucial  phase  is  initiated 
without  fail-operational  capability,  is  expanded  into  three  relevant 
functional  areas,  or  Level-3  events:  sensing  aircraft  attitude  and 

position,  computation  of  required  outputs,  and  servo  response  to  computed 
commands.  The  first  of  these,  the  sensing  function,  is  expanded  in  Figure 
7  into  the  various  parameters  needed  by  the  FCC's  in  the  automatic  landing 
control  laws.  At  this  and  higher  levels,  the  fault  tree  is  functionally 
oriented:  failures  are  in  terms  of  loss  of  function  rather  than  loss  of 

hardware. 

The  fault  tree  stub  of  Figure  8  extends  the  sensing  function  for 
normal  acceleration  to  the  individual  hardware  elements  used  to  measure  the 
acceleration  and  transmit  it  to  the  computers.  The  failure  of  the  normal 
acceleration  signal  No.  1  to  be  present  in  all  computer  channels  can  be 
caused  by  loss  of  the  sensor  itself,  associated  wiring,  or  one  of  the 
circuit  cards  Involved  in  receiving  the  signal  and  transmitting  it  to  all 
channels.  Volvxne  II,  Figure  5. 1.1. 3.1  shows  the  functional  flow  of  these 
cards.  The  A24  Autoland  Sensor  Input  and  A27  Discrete  Input  Cards  are  both 
involved:  The  A24  card  handles  the  analog  acceleration  signal  and  the  A27 
card  handles  the  validity  discrete  signal.  The  processor  Itself  is  not 
involved  in  the  data  acquisition  process  and  so  is  not  shown.  At  this 
level,  the  transition  has  been  made  from  required  funcltons  to  the  hardware 
which  performs  those  functions. 

Failure  of  the  system  to  provide  a  NO  DUAL  annunciation  is  shown  in 
Figure  9.  This  figure  is  of  particular  interest  because  of  the  explicit 
software  function  Identified.  A  failure  rate  of  zero  is  assigned  to 
failure  of  this  function,  because  it  can  be  explicitly  and  exhaustively 
tested.  Once  it  has  been  so  tested,  the  probability  of  both  NO  DUAL 
annunciations  failing  because  of  a  generic  software  error  is  taken  to  be 
zero.  A  generic  software  error  is  a  discrepancy  in  the  software  which  will 
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Figure  7,  Sensing  Function 
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cause  all  computer  channels  which  use  that  software  to  produce  the  same , 
but  wrong,  result.  Multiple  computer  channels  do  not  provide  redundancy 
with  respect  to  generic  software  errors  as  long  as  the  same  software  is 
used  in  all  channels,  as  it  is  in  most  contemporary  systems,  including  the 
RDFCS.  Reference  7  may  be  consulted  for  a  discussion  of  software  errors, 
and  RTCA  Document  DO-178  should  be  consulted  for  a  discussion  of  software 
test  requirements. 

Fault  tree  stubs  similar  to  that  shown  in  Figure  8  were  developed  for 
the  other  sensors  of  Figure  7.  These  are  very  much  like  the  stub  shown  in 
Figure  8  and  so  are  not  included  in  the  report. 

The  second  of  the  Level-3  events  of  Figure  6  is  that  the  crueial 
flight  phase  is  initiated  without  fail-operational  computing  oapability  and 
that  an  additional  component  failure  causes  system  failure  before  the  phase 
is  complete.  This  is  shown  in  Figure  10  as  four  Level-4  events.  The  first 
of  these,  that  channel  A  of  FCC  No.  1  fails  above  alert  height,  can  be 
caused  by  either  channel  of  the  FCC  failing  to  produce  a  required  output, 
as  shown  by  the  eight  events  at  the  lowest  level  (Level-5)  in  Figure  10. 

Figure  11  continues  the  development  of  the  fault  tree  for  one  of  the 
Level-5  events  of  Figure  10.  This  event,  failure  of  the  A  channel  of  FCC 
No.  1  to  produce  a  rudder  command,  can  be  caused  by  failure  of  any  one  of 
several  cards  within  the  channel.  In  this  study,  the  two  cards  which  make 
up  the  processor  were  considered  in  more  depth  than  the  others.  These  two, 
the  A13  Control  Card  and  the  A14  Data  Path  Card,  are  shown  in  Figures  12 
and  13,  respectively,  in  terms  of  the  modules  described  in  Section  5. 1.1.1, 
Volume  II.  Also  shown  in  each  of  Figures  12  and  13  is  a  subevent  for 
failure  of  a  miscellaneous  part,  such  as  the  circuit  board,  the  edge 
eonnector,  or  other  part  which  is  not  included  in  one  of  the  modules  nasMd 
in  the  other  blocks. 

Theoretleslly,  the  fault  tree  analysis  of  the  failure  of  the  prooessor 
to  compute  the  rudder  command  can  be  continued  below  the  module  level  to 
the  individual  Integrated  circuit  pins  or  discrete  piece-parts.  The 
desirability  of  doing  this  is  questionable,  however,  because  of  the  nature 
of  the  processor.  The  processor  is  not  designed  to  perform  a  single 
specific  function,  such  as  computing  rudder  commands.  It  is  designed  to 
efficiently  perform  a  number  of  simple  functions,  suoh  as  addition. 
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multiplication,  and  logic  operations.  A  suitable  sequence  of  such 
operations  (i.e.,  the  flight  software)  is  used  to  make  the  processor 

generate  the  rudder  command,  the  aileron  command,  and  so  forth.  It  is  much 
easier  to  relate  the  modules  and  integrated  circuits  (IC)  to  the  simple 

functions  (add,  multiply,  etc.)  than  to  the  much  more  complicated  functions 
of  computing  the  command  for  a  particular  servo. 

It  is  also  easier,  in  general,  to  relate  a  specific  failure  mode  of  an 
integrated  circuit  within  the  processor  to  its  effect  on  the  processor 

operation  than  to  start  with  the  effect  and  then  work  in  the  other 

direction  to  the  IC  failure  modes  which  would  produce  the  effect.  In  other 
words,  it  is  easier  to  do  an  FMEA  than  a  fault  tree  analysis  at  this  level. 

Another  reason  for  preferring  FMEA  to  fault  trees  at  this  level  is 
that  in  the  course  of  performing  the  fault  tree  analysis,  the  analyst  must 
account  for  all  of  the  ways  the  processor  can  fail;  that  is,  all  of  the 
ways  in  which  the  processor  output  can  be  wrong. 

These  ways  are  the  failure  modes  of  the  processor.  Each  of  these 
modes  must  then  be  traced  to  all  possible  combinations  of  IC  pin  failures 
which  could  produce  the  processor  failure  mode.  Because  processors  have 
many  different  possible  outputs,  there  are  a  high  nianber  of  ways  that  the 
output  oould  be  wrong.  There  is  no  practical  way  of  assuring  that  all  of 
these  possibilities  have  actually  been  covered  in  the  fault  tree.  The  FMEA 
requires  that  all  pin-level  IC  failure  modes  be  considered.  These  modes 
are  much  better  understood,  and  there  are  less  of  them,  so  that  it  is  much 
easier  to  be  certain  that  they  have  all  been  covered.  This  is  not  meant  to 
imply  that  a  complete  pin-level  FMEA  is  easy  or  inexpensive;  it  is  neither. 

In  light  of  the  foregoing  considerations,  the  fault  tree  analysis  of 
the  processor  was  not  continued  below  the  level  developed  in  Figures  12  and 
13.  Instead,  the  FMEA  approach  was  used  as  described  in  Section  6. 

To  continue  with  the  development  of  other  branches  of  the  fault  tree. 
Figure  14  develops  the  event  of  Figure  11  that  the  pilot  is  not  warned  that 
FCC  Mo.  1  A  channel  is  not  generating  a  correct  rudder  command.  This 
portion  of  the  fault  tree  Includes  several  software  functions.  In  a 
production  program,  the  test  requirements  of  each  of  these  functions  should 
be  reviewed  to  confirm  that  they  satisfy  the  criteria  of  RTCA  Document 
DO-178  (Reference  2).  In  this  project,  conducted  for  illustrative 
purposes,  this  review  was  not  made. 
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Similar  tree  stubs  to  that  developed  in  Figures  11-14  were  developed 
for  the  other  required  outputs  from  Channel  A  of  FCC  No.  1  and  the  other 
three  channels  (Figure  9).  They  are  not  included  here  because  they  are 
quite  repetitive  of  the  analysis  shown. 

The  last  of  the  Level-3  events  of  Figure  6  is  that  the  crucial  phase 
is  initiated  without  fail-operational  servo  capability  and  a  debilitating 
failure  occurs.  This  is  expanded  in  Figure  15  into  the  three  aircraft 
control  axes:  roll,  pitch,  and  yaw.  Figure  16  shows  the  fault  tree  for 
failure  of  the  No.  1  yaw  autopilot  servo,  with  the  servo  failure  not 
annunciated  to  the  crew. 

Fault  tree  stubs  for  the  other  5  servos  of  Figure  15  were  developed  to 
complete  the  analysis  of  the  Level-3  events  of  Figure  6.  These  are  quite 
similar  to  the  stub  shown  for  the  rudder  servo  and  are  not  Included  in  the 
report.  This  completes  the  discussion  of  the  second  of  the  Level-2  events 
of  Figure  6. 

The  third  of  the  Level-2  events  of  Figure  6  is  that  multiple  failures 
occur  during  the  crucial  flight  phase  and  these  occur  in  a  combination 
which  causes  system  failure.  Figure  17  shows  the  initial  development  of 
this  event  to  lower  levels.  Continuing  this  development  produces  a  major 
branch  of  the  fault  tree  quite  similar  but  simpler  to  that  for  the  second 
of  the  Level-2  events.  It  differs  primarily  in  that  the  NO  DUAL 
annunciation  does  not  appear,  since  that  particular  warning  is  suppressed 
during  the  crucial  phase.  Since  that  major  branoh  is  so  similar  to  that 
already  discussed,  it  is  not  describedd  further  here. 

QUANTITATIVE  FAULT  TREE  ANALYSIS 

System  failure  probability  was  oomputed  from  the  fault  tree  using  the 
hardware  failure  rates  presented  in  Section  8.  A  failure  rate  of  zero  was 
used  for  each  software  function,  since  there  is  currently  no  acceptable  way 
of  predicting  DFCS  software  failure  rates  (Reference  2,  Section  2.2.1). 

Considering  hardware  failure  modes  only,  the  probability  of  initiating 

the  crucial  phase  with  less  than  fail-operational  capability  and  a  second 

—14 

failure  debilitating  the  system  was  calculated  to  be  2.46  x  10  .  This  is 

based  on  a  flight  time  of  4.0  hours  prior  to  the  oruoial  phase  and  a 
crucial  phase  duration  of  0.02  hours. 


MULTIPLE  FAILURES 
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The  probability  of  the  system  failing  because  of  multiple  failures 

-9 

during  the  crucial  phase  was  calculated  to  be  0.638  x  10  .  This  is  based 

on  a  crucial  phase  duration  of  0.02  hours. 

The  system  failure  probabilities  computed  are  actually  upper  bounds  on 
the  actual  failure  probabilities.  This  is  because  the  fault  trees  are 
based  on  the  assumption,  for  many  items,  that  all  failure  modes  of  the  item 
render  the  item  incapable  of  performing  any  of  its  functions.  For  example, 
certain  buffers  on  the  A26  Data  Acquisition  Card  are  used  for  sensor  data 
which  is  not  required  for  automatic  landing,'  apd  so  at  least  some  of  the 
failures  of  these  buffers  would  not  prevent  the  card  from  correctly 
handling  required  data.  However,  the  failure  rates  used  in  the  analysis 
are  for  the  entire  card,  including  these  buffers,  so  that  the  failure 
probability  calculated  for  the  card  includes  card  failure  modes  which  would 
not  affect  automatic  landing. 


TABLE  2.  QUANTITATIVE  RESULTS 


Fault 

Tree 

CARSRA 

Probability  Of 

Result 

Result 

Unannunciated  Failure 
in  Cruise  and  Second 

Failure  in  Landing 

2.46  x  10~14 

3.36  x  10“ - 4 

Multiple  Failures 

In  Landing 

0.64  x  10'9 

0.66  x  10-9 
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6.  FAILURE  HOPE  AMP  EFFECT  AMALTSI3 


tOU  Ii  UTTEOIATEP  ASSUIAHCE 


As  stated  in  Section  5,  fault  tree  analysis  provides  assurance  that 
aost  system  eoaponents,  suoh  as  analog  sensors  and  servos,  have  no  single 
failure  aode  which  produces  systea  failure.  This  is  because  such 
eoaponents  have  only  a  few  possible  failure  nodes,  and  it  frequently  is  not 
necessary  to  distinguish  in  the  fault  tree  among  these  modes.  When  it  is 
necessary  to  distinguish  among  modes,  it  is  usually  fairly  slaple  to 
Identify  the  modes  which  are  relevant  in  the  branch  of  the  tree  being 
developed.  The  analysis  can  often  be  extended  below  the  ooaponent  level  to 
the  failure  aodes  of  the  individual  piece-parts  which  comprise  the 
ooaponent.  Analysis  to  this  very  detailed  level  is  sometimes  necessary  to 
ascertain  that  a  component  has  no  failure  modes  which  could  reaain 
undetected  until  a  second  failure  occurs  elsewhere  in  the  system. 

Fault  tree  analysis  is  cumbersome  and  inefficient  if  extended  froa 
systea  level  to  the  integrated  circuit  pin  level  in  the  processor  of  a 
digital  systea,  however.  Basically,  this  is  a  result  of  two  basio 
characteristics  of  digital  systems : 

1.  Functions  which  are  described  very  simply  at  a  higher  level 
(e.g.,  sensor  monitoring)  require  a  myriad  of  sequential 
operations  at  the  integrated  circuit  level.  These  operations  are 
required  to  obtain  the  proper  data,  route  it  to  the  proper 
registers  within  the  arithmetic  logic  unit  (ALU)  where  arlthaetlo 
and  logic  operations  are  actually  performed,  and  route  the 
results  too  the  proper  storage  register  or  output  port.  Many 
different  integrated  circuits  are  involved  in  each  of  these 
operations. 

2.  Many  interfaces  between  integrated  cirouits  Involve  several 
pins,and  it  is  the  ooablnstion  of  pin  states  (eleotrieally  high 
or  low)  which  is  significant.  That  is,  eaoh  combination  of  pin 
states  represents  a  different  data  value  or  instruction,  aad  the 
effect  of  a  single  pin  being  in  the  wrong  (faulted)  state  depends 
on  the  state  of  the  other  (non-faulted)  pins. 
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The  net  result  of  these  characteristics  of  digital  hardware  is  that 
there  are  many  more  integrated-circuit-level  operations  performed  in 
executing  the  flight  software  than  there  are  pin-level  failure  modes.  In 
extending  a  fault  tree  analysis  from  failure  of  system-level  functions  to 
failure  of  integrated  circuit  pins,  all  of  these  detailed  operations  must 
be  included  and  accounted  for,  an  extremely  inefficient  process.  Once  the 
fault  tree  had  been  fully  developed,  another  extremely  laborious,  task  would 
remain:  reviewing  the  tree  to  make  certain  (1)  that  all  of  the  failure 

modes  of  the  Integrated  circuits  had  been  accounted  for,  and  that  no 
failure  mode  could  remain  undetected  until  a  second  failure  occurred,  with 
the  combined  effect  of  both  faults  producing  a  hazardous  condition;  and  (2) 
that  no  failure  mode  could  by  itself  produce  a  hazardous  condition. 

Failure  mode  and  effect  analysis  provides  a  means  of  systematically 
examining  all  of  the  potential  failure  modes  of  the  integrated  circuits  to 
confirm  that  none  of  them  could  cause  a  hazard  directly  or  remain  latent 
and  subsequently  cause  a  hazard  in  conjunction  with  a  second  failure. 

GEMEHAL  COMSIDERATIOMS 

In  conducting  the  pin-level  failure  mode  and  effect  analysis  of  a 
processor,  three  factors  greatly  reduce  the  effort.  The  first  factor  is 
that  propagation  of  most  faults  under  all  conditions  does  not  have  to  be 
considered.  A  single  effect  can  usually  be  found  which  will  totally 
debilitate  the  processor.  For  example,  a  faulted  processor  output  pin  will 
result  in  the  processor  trying  to  read  about  half  of  th®  data  and  maohine 
level  instructions  from  the  wrong  memory  addresses.  This  will  result  in 
the  coil  current  comparators  tripping,  sensor  comparisons  falling,  and  in 
the  case  of  the  REFCS,  the  Iteration  monitor  will  fail.  In  a  system  using 
check-suns  to  monitor  program  memory  integrity,  these  tests  will  fall. 

The  second  factor  which  reduces  the  effort  is  that  many  pairs  of 
faults  will  have  the  same  effect.  There  are  nunerous  instances  of  an 
output  pin  on  one  IC  being  connected  only  to  one  other  pin.  If  either  pin 
falls  open,  the  effect  will  be  the  same.  Similarly,  a  ground  fault  in 
either  pin  will  produce  the  same  effeot. 
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The  third  factor  which  reduces  the  effort  is  that  there  are  many 
instances  in  which  three  pins  are  connected  so  that  one  output  pin  drives 
two  input  pins  on  different  circuits.  An  open  fault  at  each  of  the  input 
pins  can  be  evaluated  first.  An  open  fault  at  the  output  pin  is  then 
equivalent  to  both  input  pins  failing  open  simultaneously,  and  in  most 
cases  the  effect  is  the  "sum"  of  the  effects  of  the  input  pins  failing 
open;  that  is,  both  effects  occur.  If  both  input  pins  are  on  the  same 
chip,  the  effect  of  both  being  open  is  more  likely  to  differ  from  the  sum 
of  the  individual  effects.  See  Figure  18. 

The  effect  of  any  of  the  three  pins  failing  shorted  to  ground  is  the 
same  in  either  of  the  two  cases  of  Figure  18. 

Another  frequently  encountered  condition  Involving  three  pins  is  two 
outputs  connected  to  a  single  input  (Figure  19).  In  such  a  case,  chips  A 
and  B  will  have  three-state  outputs,  and  one  or  both  outputs  should  be  in 
the  high-impedence  state  at  all  times.  An  open  fault  on  the  output  pin  of 
chip  A  will  then  only  affect  chip  C  when  A  has  its  output  enabled.  Simi¬ 
larly,  an  open  fault  on  the  output  pin  of  chip  B  will  only  affeot  chip  C 
when  B  has  its  output  enabled.  An  open  fault  on  the  chip  C  input  pin  will 
usualy  produce  the  sum  of  the  effects  of  open  faults  on  the  two  output 
pins.  A  ground  fault  on  any  of  the  three  pins  will  have  the  same  effect. 

Still  referring  to  Figure  19,  if  a  fault  should  occur  which  results  in 
both  enable  pins  being  in  the  ensble  stste,  there  is  a  possibility  of 
damage  to  the  A  or  B  chip.  If  one  output  is  high  and  the  other  low,  there 
could  be  a  low  impedance  path  to  ground,  through  the  output  pins,  whioh 
could  burn  out  the  A  or  B  chip.  This  depends  on  the  technology  used  in  the 
individual  chips.  Frequently,  the  effect  of  the  original  ground  fault  oan 
be  Judged  to  be  a  total  processor  failure  whether  or  not  the  seoondary 
damage  ooours. 

APPLICATION  OF  MFCS 


In  this  study,  three  modules  of  the  processor  (Figure  20)  ware 
considered  at  pin  level  (Ref.  Vol.  II,  Section  5. 1.1.1): 

o  The  Instruction  mspper  prom,  which  consists  of  three  prom  chips 
in  parallel 
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Z  HI 


FIGURE  20 


o  The  microprogram  sequencer,  which  consists  of  three  2911 
sequencer  chips  in  parallel 

o  The  microprocessor  module,  which  consists  of  4  chips  in  parallel. 
Each  of  these  chips  is  a  290 1A. 

The  instruction  mapper  prom  chips  are  read-only  memory  chips.  The 
inputs  to  the  chip  are  machine-level  operation  codes  and  the  depth  of  the 
stack  maintained  in  the  2901  microprocessors.  These  are  connected  to  the 
address  pins  of  the  mapper.  The  data  stored  in  the  prom  is  the  oontrol 
store  prom  address  of  the  first  microcode  instruction  required  to  execute 
the  machine  level  instruction  with  the  processor  stack  at  a  particular 
depth.  The  mapper  output  pins  are  only  active  at  the  beginning  of  a 
microcode  sequence,  at  which  time  a  chip  enable  signal  is  sent  to  the 
mapper  from  the  next  address  control  prom. 

The  microcode  address  from  the  mapper  prom  is  routed  to  the 
microprogram  sequencer  module.  This  module  generates  a  sequence  of 
microcode  addresses,  beginning  with  the  starting  address  froei  the  mapper 
prom.  Some  microcode  routines  involve  jtmps  to  a  new  address  rather  than 
sequential  progression  only.  In  such  cases,  the  microprogram  sequencer 
receives  the  Jump  address  from  the  control  store  proms  and  resumes 
sequential  generation  of  addresses. 

The  microprocessor  module  is  composed  of  four  290 1A  microprocessor 
chips.  Each  chip  has  a  word  size  of  4  bits,  so  that  the  four  chips  in 
parallel  are  used  to  provide  the  processor  16-bit  word  size.  This  requires 
that  carry  signals  be  passed  between  2901A's  during  arithmetic  operations. 
Other  Interconnections  between  2901A's  are  used  for  data  shift  operations. 

The  290lA's  are  controlled  primarily  by  control  signals  from  the 
control  store  proms  in  conjunction  with  the  outputs  from  various  registers. 
Section  5. 1.1.1  of  Volune  II  should  be  consulted  for  further  information  on 
the  functions  of  these  registers  and  other  processor  modules. 

The  failure  mode  and  effect  analysis,  simmarlzed  in  Table  3.  (in 
Appendix  A)  considered  three  types  of  pin-level  faults:  open,  grounded, 
and  shorted  to  supply  voltage.  In  most  cases,  the  effect  of  a  fault  can  be 
assessed  by  using  the  chip  logic  diagrams,  a  description  of  ohip/module 
functions  and  the  schematic  diagrams  (Voluae  II,  Sections  5. 1.1.1.  - 
5. 1.1.5).  The  schematic  diagrams  are  reproduced  in  Appendix  C. 
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The  effect  of  certain  pin  faults  cannot  be  determined  by  analysis 
using  just  the  information  mentioned  above.  In  particular,  the  contents  of 
specific  prom  addresses  is  needed  in  some  cases.  In  other  cases  the 
machine-level  code  is  needed  along  with  the  microcode  sequences  and 
addresses.  Alternatively,  the  faults  can  be  inserted  and  the  effect 
observed.  This  approach  was  taken  in  this  study  and  the  results  are 
presented  in  Section  7.  For  example,  it  was  known  that  failure  of  one  of 
the  processor  pins  used  in  data  shifts  (RO,  R3,  QO,  Q3  stuck  high  or  low), 
there  would  be  an  immediate  disconnect  if  certain  of  the  integer  words  made 
up  of  packed  Boolean  variables  were  shifted.  It  was  determinable  from  the 
available  information  that  such  shifts  might  occur,  but  it  was  not 
determinable  that  they  definitely  would  occur.  Volume  II,  Tables 
5. 1.4. 3. 3. 3  and  5. 1.4.3.3.4  show  examples  of  such  packed  words.  Similarly, 
if  certain  fixed-point  numbers  were  shifted  during  computation,  the 
conmands  to  the  servos  would  be  in  error  and  the  coil  current  comparators 
would  trip.  While  both  left  and  right-shifts  are  normally  used  in 
multiplication  algorithms,  it  was  not  determinable  that  a  stuck  shift  bit 
would  definitely  cause  such  a  trip.  When  the  faults  were  actually 
inserted,  the  processor  stopped  immediately.  ("Laned lately,"  as  viewed  by 
the  human  observers.)  In  this  way,  fault  insertion  confirmed  the  overall 
effect,  massive  processor  failure  and  disengagement  of  the  servos,  but  the 
exact  mechanism  by  which  it  occurred  was  not  determined. 


7.  fault  imsebtiob 


ROLE  II  INTEGRATED  APPROACH 


Fault  Insertion  is  used  in  the  integrated  assurance  approach  for  three 
purposes  as  shown  in  Table  1.  These  are: 

1.  Faults  are  inserted,  on  a  sampling  basis,  to  confirm  the  fault 
effects  reflected  in  the  fault  tree  analysis  and  fault  effects 
determined  during  failure  mode  and  effect  analysis.  This  Includes 
faults  of  components  (sensors  and  servos  in  this  study)  and  faults 
of  integrated  circuits  (pin-level  faults  in  the  digital  proces¬ 
sor)  . 

2.  Faults  sre  Inserted,  also  on  a  sampling  basis,  to  confirm  fault 
deteotlon  and  annunciation  functions  implemented  in  the  system. 
Many  of  these  are  also  inserted  to  aonfirm  effeots,  so  that  they 
are  inserted  for  two  specific  purposes. 

3.  Faults  are  Inserted  to  determine  the  effect  when  the  analysis  is 
intractable  or  When  there  is  some  uncertainty  in  the  analysis 
result. 

APPLICATION  TO  RDFC3 


The  RDFCS  simulator  at  NASA-4mes  was  used  to  Insert  the  faults  shown 
in  Table  A  (in  Appendix  B).  The  faults  were  of  two  general  types: 
component  level  faults  and  integrated  circuit  pin  faults.  The  component 
level  faults  were  inserted  using  the  FCC  breakout  panels  (Figure  21),  the 
Servo  Simulator  Panel  (Figure  22),  and  the  NDICU.  Single-sensor  faults  are 
those  numbered  1  through  19  in  Table  A. 

Faults  representing  a  dead  sensor  or  a  broken  wire  from  the  sensor  to 
the  FCC  were  Inserted  by  pulling  the  appropriate  jumper  plug  at  the  break¬ 
out  panel.  Faults  representing  missing  sensor  validity  discretes  were  also 
Inserted  in  this  way,  although  they  can  also  be  inserted  via  the  Disorete 


Figure  21.  CAPS  Test  Adapter  and  Computer  Breakout  Panel 
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Switch  Panel  (Figure  23).  Sensor  hardovers  and  ramps  were  inserted  using 
the  MDICU.  Servo  faults  were  inserted  using  the  Servo  Simulator  Panel. 

For  monitoring  the  processor  detection  of  sensor  faults,  the  CAPS  test 
Adapters  (CTA)  were  used.  One  of  the  CTA  address  windows  was  set  to  the 
adddress  of  the  Executive  Failure  (Status)  Word  (EFW)  in  each  computer 
channel.  The  EFW  is  a  16-it  word  with  each  bit  representing  a  discrete 
piece  of  information  and  there  is  one  EFW  for  each  sensor  type  in  each 
computer  channel.  The  4  low-order  bits  (0-3)  represent  respectively 
failure  of  the  My  A  (EFMA) ,  My  B  (EFMB) ,  Other  A  (EFOA) ,  and  Other  B  (EFMB) 
sensor  signals.  The  other  12  bits  have  functions  as  described  in  Volume 
II,  Table  5.1.2. 4.2,  which  are  not  of  concern  here.  The  data  window  of  the 
CTA  shows  the  status  of  the  EFW  as  four  hexadecimal  characters,  with  the 
right-most  character  representing  the  bits  of  interest,  0-3. 

The  effect  of  a  sensor  signal  being  detected  bad  by  the  software  sen¬ 
sor  monitor  is  that  certain  bits  are  changed  from  0  to  1.  With  no  failures 
detected,  EFMA,  EFMB,  EFOA,  and  EFOB  are  all  0,  which  is  represented  in 
hexadecimal  notation  as  0.  (0000  binary  =  0  hexadecimal.)  When  the  number 

1  sensor  of  a  triple  sensor  complement  is  detected  to  have  failed,  bit  0 

(EFMA)  is  set  to  1  in  both  channels  of  FCC  No.  1.  Bit  1  is  also  set  to  1 

* 

so  that  the  comparison  monitoring  will  work  properly  on  the  two  remaining 
sensors.  The  EFW  low  order  bits  will  then  be  0011,  which  is  3  in  hexa¬ 
decimal.  The  net  effect,  then,  of  the  number  1  sensor  of  a  triple  sensor 
set  falling  is  that  the  value  displayed  in  the  CTA  window  changes  from  0000 
to  0003.  The  left-most  three  hexadecimal  digits  each  remains  at  0  since 
each  of  the  corresponding  binary  bits  (4-15)  of  the  EFW  remains  at  0. 

Fault  cases  1  through  8  were  used  to  show  that  the  software  sensor 
monitor  subroutine  is  implemented  correctly  in  the  RDFCS  by  subjecting  it 
to  a  number  of  different  faults  in  the  same  sensor ^ype.  These  cases  were 
also  used  to  show  that  the  results  of  the  sensor  monitoring  are  accounted 
for  in  the  implementation  of  the  NO  DUAL  equation,  which  is  also  in  soft¬ 
ware.  Cases  9  through  16  were  then  used  to  show  that  the  voter  is  involved 
for  various  sensor  types.  Rigorous  validation  of  the  system  by  testing 
would  require  that  faults  be  Inserted  for  all  sensor  types  used  in 
automatic  landing.  In  this  study,  performed  for  illustrative  purposes,  the 
full  complement  of  sensor  types  was  not  faulted. 
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Figure  23.  Discrete  Switch  Panel 
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In  case  2E,  NO  DUAL  did  not  annunciate  even  though  the  fault  was  in¬ 
serted  with  the  airplane  inbound  to  the  ILS  beam  intercept  point.  It  is 
believed  to  be  the  result  of  the  inbound  leg  being  flown  at  an  unrealis¬ 
tically  low  altitude,  so  that  the  airplane  did  not  track  the  glideslope 
bean  for  25  seconds  before  passing  through  150  ft  altitude.  A  review  of 
the  NO  DUAL  annunciation  logic  (Volume  II,  Section  5. 1.2.3. 1.3)  shows  that 
this  is  the  most  likely  cause,  since  AP.ONEFAIL  was  set  to  true.  Low 
approaches  (1500  ft)  were  being  simulated  in  the  interest  of  time.  Approach 
altitude  was  subsequently  raised  to  2000  ft. 

Faults  17  through  19  were  used  to  confirm  the  servo  monitoring  and  the 
tie-in  of  the  servo  monitor  outputs  to  the  NO  DUAL  and  disconnect  logic. 
The  servo  monitors,  in  particular  the  coil  current  comparators,  are  quite 
important  in  ensuring  that  the  airplane  does  not  enter  the  crucial  phase 
with  a  faulty  computer  or  servo. 

Fault  cases  43  through  45  were  used  to  confirm  that  the  FCC's  will 
both  disengage  upon  loss  of  the  second  sensor,  with  the  AP.DISC  warning 
displayed,  in  accordance  with  the  system  description,  Volune  II,  Section 
4.3.6. 1. 

At  the  integrated  circuit  pin  level,  a  number  of  open  and  ground 
faults  were  inserted  to  confirm  the  FMEA  results  of  Section  6.  For  this 
activity,  one  of  the  FCC's  was  removed  from  the  pallet  and  the  card 
containing  the  chip  to  be  faulted  '■>'  s  extended  for  access  as  shown  In 
Figure  24.  Figure  25  shows  the  prc  ^sor  Data  Path  card. 

Open  pin  faults,  Cases  20  through  23,  were  inserted  by  using  multiple 
sockets  between  the  chip  and  the  circuit  card,  with  a  jumper  wire  replacing 
the  normal  pin-to-socket  connection.  Each  fault  was  inserted  by  physically 
pulling  the  jumper  to  open  the  connection.  This  is  a  slow  procedure,  since 
the  chip  must  be  removed  and  the  Jumper  wire  rigged  on  the  desired  pin.  The 
chip  and  sockets  must  then  be  installed  and  the  processors  brought  back  up. 
This  means  of  inserting  open  pin  faults  is  only  marginally  satisfactory. 
It  would  be  much  easier  to  do  if  a  stack  of  5  or  6  sockets  could  be  used 
between  the  chip  and  the  circuit  card.  However,  the  proceaaor  will  not 
come  up  with  more  than  three  sockets  stacked.  The  longer  electrical  paths 
resulting  from  the  use  of  the  extender  cad  apparently  come  close  to 
exhausting  the  available  tolerance  in  the  timing  of  the  individual  micro- 
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steps,  and  the  extra  path  length  and  capacitance  caused  by  more  than  three 
sockets  disables  the  processor. 

Grounded  pin  faults  are  much  easier  to  insert,  since  the  chip  does  not 
have  to  be  removed  to  set  up  each  case.  The  processor  does  have  to  be 
brought  back  up  each  time,  but  this  is  a  fairly  rapid  step.  Before  each 
fault  was  inserted,  the  data  sheets  from  the  chip  manufacturer  were 
reviewed,  along  with  the  card  schematics,  to  determine  that  the  fault  would 
not  damage  any  chips.  No  chips  were  damaged  by  the  ground  faults.  The 
ground  pin  faults  are  cases  24  through  42  in  Table  3. 

The  chip  pin  faults  all  disabled  the  processor,  with  the  exception  of 
open  pin  fault  21.  This  fault  involves  a  pin  of  a  quad  2-input  NOR  gate. 
The  fault  had  no  effect  on  the  processor  operation. 

FAULT  INSERTION  RESULTS 

The  faults  inserted  in  the  RDFCS  simulator  achieved  the  desired  re¬ 
sults  in  the  assurance  assessment  of  this  study  ,  and  more  importantly 
confirmed  that  fault  insertion  is  capable  of  providing  the  results  required 
of  it  in  the  integrated  assurance  approach.  Specifically,  the  faults 
inserted  confirmed  (1)  that  the  NO  DUAL  warning  appears  when  it  should,  (2) 
that  all  sensor  types  faulted  and  required  for  automatic  landing  are 
monitored,  (3)  that  the  servo  monitoring  functions  correctly,  (4)  that  the 
effect  of  pin-level  faults  in  the  processor  is  in  agreement  with  the 
failure  mode  and  effect  analysis,  and  (5)  that  fault  Insertion  is  a 
reasonable  way  of  resolving  uncertainty  of  the  effect  of  open  and  grounded 
pin  faults  in  digital  hardware.  While  these  results  were  obtained  on  a 
particular  system,  the  approach  is  judged  to  be  viable  for  validating  other 
digital  systems. 


8.  FAILURE  RATE  DEVELOPMENT 


The  failure  rates  for  servos,  sensors,  and  indicators  were  taken  from 
the  data  base  maintained  by  the  Lockheed-Georgia  Company  Reliability 
Engineering  Department.  They  are  composite  values  for  representative 
components  of  comparable  complexity  and  construction. 

The  failure  rates  for  the  integrated  circuits  of  the  Data  Path  and 
Control  Cards  were  estimated  using  the  formulas  and  tables  of  Military 
Handbook  217C  (Ref.  8).  The  formulas  provide  a  means  of  accounting  for  a 
significant  number  of  factors: 

1.  Device  technology 

2.  Device  complexity 

3.  Junction  temperature 

4.  Package  technology 

5.  Applicaiton  environment  (voltage) 

6.  Usage  environment 

7.  Quality  level 

For  example,  the  equation  for  the  failure  rate  of  a  monolithic  bipolar 
device  is: 

f  =  Kq  [C^Ky  ♦  (C2  ♦  C3)  Ke]  Kl 

where: 

f  is  the  device  failure  rate 
Kq  is  the  quality  factor 

K^.  is  the  temperature  adjustment  factor  for  junctions 

fCy  is  the  voltage  derating  stress  factor 

Kg  is  the  applicaiton  environment  factor 

C^  and  Cg  are  complexity  factors  based  on  transistor  count 

C^  is  a  complexity  factor  based  on  package  technology  and  number  of 

pins 

K^  is  a  learning  factor. 
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The  quality  factor,  K^,  has  a  value  of  1  for  devices  procured  in  full 
accordance  with  MIL-M-38510  (Ref.  9),  Class  B  requirements.  This  value  was 
used  for  all  circuits  in  this  project.  It  should  be  noted  that  the  quality 
factor  is  a  direct  multiplier,  so  that  the  predicted  rate  is  proportional 
to  it.  More  or  less  stringent  quality  factors  can  therefore  greatly 
influence  the  prediction  for  any  individual  circuit,  circuit  board,  or  an 
entire  component. 

Junction  temperatures  are  used  in  determing  the  adjustment  factors  K^. 
The  junction  temperature  is  ambient  temperature  plus  the  differential 
resulting  from  power  dissipation  through  the  ease.  An  ambient  of  60°C 
was  used,  with  the  power  dissipation  taken  from  the  circuit  specification. 

The  voltage  derating  stress  factor  is  1  for  the  bipolar  circuits  used 
in  the  CAPS  processor.  The  application  environment  factor  is  3.5  for  the 
airborne,  inhabited,  transport  environment  of  the  aircraft  underdeck 
avionics  rack.  Failure  rates  for  the  circuit  cards  of  the  FCC's  were 
obtained  by  summing  the  failure  rates  for  the  card  and  its  components. 
Table  5  sunmarizes  the  failure  rate  prediction  for  the  A13  control  card. 
Failure  rates  for  the  other  cards  are  shown  in  Table  6. 

Table  7  presents  failure  rates  for  the  system  components  other  than 
the  FCC's. 

In  using  these  rates  in  the  fault  tree  and  CARSRA  analyses,  an 
adjustment  was  frequently  required  to  include  only  a  portion  of  the  rate, 
since  only  certain  failure  modes  are  of  Interest.  For  example,  each  dual 
current  comparator  has  a  predicted  failure  rate  of  0.03.  Each  half  of  the 
comparator  is  given  a  rate  of  .01  for  the  failure  mode  of  failing  to  trip 
when  the  threshold  difference  is  exceeded.  This  is  a  very  conservative 
rate  for  this  mode. 


TABLE  5.  FCC  CONTROL  CARO  FAILURE  RATE 

ITEM  FAILURE  RATE* 

Integrated  circuits 
Resistors 
Capacitors 
Oscillator 
Coil 

Circuit  Board 
Edge  Connector 

Control  Card  2.45 

*A11  failure  rates  in  failures  per  million  hours. 


1.788 

.0018 

.224 

.25 

.0007 

.023 

.16 
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TABLE  6.  PREDICTED  FCC  CARD  FAILURE  RATES 


CARD  NO. 

A 1  Power  Supply  MoniCor 

A2-A5  Prom  Card 

A6  Power  Supply  MoniCor 

A7  -  A10  Prom  Card 

All  Terminator/Tesc  Access 

A12  RAM  Memory  Control 

A  1 3  CAPS  ConCrol 

A  1 4  CAPS  Data  Path 

A16  Cross-channel  Receiver 

A 17  DITS  Transmitter 

A 1 8  D/A  Servo  Command 

A 1 9  Terminator/Time  Synch 

A20  Discrete  Output 

A2  1  Data  Transmitter/Rece iver 

A22  Serial  Digital  Input  Mo.  1 

A23  Serial  Digital  Input  No.  2 

A24  Autoland  Sensor  Input 

A25  Cruise  Sensor  Input 

A26  Data  Acquisition 

A27  Discrete  Input 

A38  Servo  Engage  Logic 

A29  Cross  Channel  XMTR 

A30  -  A32  Servo  Amplifier 

A33  Speed  Servo  Amp 

A300  Speed  Command  XMTR 

A400  Power  Supply 

ASOO  Power  Supply 


FAILURE  RATE* 


0.555 


.809  each 


.809  each 


2.45 


2.79 


3.00 


21.0 
2  1 .0 


*A1 1  failure  rates  in  failures  per  million  hours. 


- 1 


TABLE  7.  FAILURE  RATES  FOR  MAJOR  RDFCS  COMPONENTS 


COMPONENT 


UNIT  FAILURE  RATE* 


Pitch  Angle  Gyro  303 

Roll  Angle  Gyro  303 

Yaw  Rate  Gyro  200 

Accelerometer  74 

Radio  Altimeter  756 

ILS  Receiver  252 

Air  Data  System  167 

Roll  Autopilot  Servo  14 

Pitch  Autopilot  Servo  15 

Yaw  Autopilot  Servo  14 

EH  Valve  Drive  Coil  1.0 

LVDT  .72 

Dual  Current  Comparator  (Hardware)  .03 

Warning  Annunciator  (per  function)  8.3 


•These  are  NOT  actual  failure  rates  for  any  particular  air¬ 
plane  or  for  any  single  component  produced  by  a  particular 
manufacturer.  They  are  representative  rates  determined  by 
a  review  of  generic  component  types  on  a  number  of  airplane 
models  in  a  variety  of  commercial  and  military  applications. 
Ail  failure  rates  per  million  hours. 
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9.  RELIABILITY  PREDICTION  USIMG  CARSRA 


CARSRA,  which  stands  for  Computer-Aided  Redundant  System  Reliability 
Analysis  (Ref.  10),  is  an  analytical  reliability  prediction  program  used  in 
the  integrated  assurance  approach  to  obtain  the  probabilitty  of  system 
failure.  In  this  study,  the  probability  of  failure  is  only  considered  dur¬ 
ing  the  crucial  flight  phase,  which  has  a  duration  of  0.02  hours. 

The  use  of  CARSRA,  along  with  the  quantitative  assessment  produced  by 
evaluating  the  fault  tree  analysis,  provides  two  independent  computations 
of  system  failure  probability.  This  reduces  the  risk  of  a  false,  low 
probability  of  failure  being  produced  by  a  single  method  and  the  error 
remaining  undetected. 

Although  CARSRA  is  identified  specifically  in  the  integrated  assurance 
approach  used  in  this  study,  some  other  method  (except  fault  tree  analysis) 
could  be  used.  If  an  alternate  method  is  used,  it  should  have  sufficient 
configuration  adaptability  to  produce  the  predicted  probability  of  system 
failure  without  requiring  simplifying  assumptions  which  would  produce  a 
false,  low  prediction.  Manual  analysis  is  a  feasible  alternative  to  CARSRA 
for  many  systems. 

CARSRA  APPLICATION 


Configuration  Description 

Three  levels  of  organization  are  implicit  in  the  CARSRA  inputs,  and 
these  levels  must  be  adhered  to  by  the  user.  At  the  top  level  is  the 
system,  in  this  case  the  RDFCS.  System  failure  probabilities  constitute 
the  primary  output  provided  by  CARSRA.  The  intermediate  level  is  comprised 
of  stages.  Each  stage  consists  of  one  or  more  identical  modules,  which  are 
at  the  lowest  level.  In  the  RDFCS,  each  sensor  is  a  module,  and  like 
sensors  form  stages.  For  example,  each  of  the  three  normal  accelerometers 
(NA)  is  a  module,  and  the  three  NA  together  comprise  a  stage. 
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Markov  Models 


Markov  models  were  selected  by  the  CARSRA  developers  as  a  major  part 
of  the  program's  analytical  framework.  The  following  discussion  of  these 
models  includes  some  material  on  applying  CARSRA  to  systems  other  than  the 
RDFCS.  This  material  is  intended  to  benefit  readers  not  familar  with  the 
rationale  of  developing  the  input  parameters  for  Markov  models  as  used  in 
CARSRA. 

A  Markov  model  is  used  to  describe  the  number  of  failed  and  operating 

modules  within  each  stage.  The  transition  rates  from  state  to  state  are 

used  to  CARSRA  in  computing  state  occupancy  probabilities.  A  separate 

Markov  model  is  used  for  each  stage.  State  1  is  the  no-failure  state  in 

each  model,  and  the  two  states  with  the  highest  numbers  correspond  to  stage 

failure.  The  Model  always  starts  in  State  1.  For  example,  a  dual  stage 

(one  of  two  identical  modules  required  for  the  stage  to  function)  might 

have  4  states,  as  shown  in  Figure  26.  State  1  represents  both  modules 

working.  State  2  represents  one  module  failed  and  one  working,  and  States  3 

and  4  represent  both  modules  failed.  The  highest  numbered  state,  4  in  this 

case,  represents  undetected  stage  failure,  while  State  3  represents 

% 

detected  failure.  Note  that  State  2  does  not  distinguish  which  module  has 
failed. 

State  transition  rates  must  be  supplied  to  CARSRA  by  the  user.  These 
are  generally  functions  of  the  module  failure  rates,  and  possibly  other 
parameters.  Returning  to  the  example  of  the  dual  stage  used  previously, 
the  Markov  state  diagram  would  be  as  in  Figure  26.  Transition  rate  f ^  ls 
rate  at  which  transitions  occur  from  State  1  to  State  2.  That  is,  if  the 
system  is  in  State  1,  the  probability  that  it  will  transition  to  State  2 
during  a  short  Increment  of  time  dt  is  f12dt.  The  other  transition  rates 
are  similarly  defined. 

If  there  is  no  monitoring  or  switching  required  when  the  first  module 
falls,  and  if  there  is  no  possibility  of  the  stage  failing  undetected,  the 
transition  from  State  1  will  always  be  to  State  2,  and  the  transition  from 
State  2  will  always  be  to  State  3.  Transition  rate  f^  will  be  simply  2f 
and  f23  will  be  f,  where  f  is  the  failure  rate  of  a  single  module.  The 
other  transition  rates  will  be  0.  Note  that  this  means  that  State  4  will 
never  be  occupied,  consistent  with  undetected  stage  failure  being  impos¬ 
sible. 
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In  many  instances  encountered  in  real  systems,  digital  or  otherwise,  a 
reconfiguration  must  occur  before  the  redundancy  can  be  availed.  In  the 
example  dual  case,  an  output  monitor  could  be  used  on  each  module.  If  the 
monitor  can  detect  971  of  module  failures,  e.g.  no  output  or  unreasonable 
output,  the  monitor  provides  "coverage",  c,  of  971.  The  transition  rate 
is  then  2fc,  so  that  971  of  the  transitions  from  State  1  go  to  State  2. 

Of  the  remaining  31  of  the  transitions  from  State  1,  some  fraction, 
e.g.  2/3,  could  go  to  State  3  and  the  rest  to  State  4.  This  would  result 
in  f13  being  2f(1-c)(2/3),  or  2f(.02),  and  f11f  being  2f(1-c)  (1/3),  or 
2f ( .01 ) . 

Note  the  distinctions  between  coverage,  which  relates  to  module  fail¬ 
ure  detection,  and  undetected  stage  failure.  Note  also  that  the  function 
of  a  particular  stage  could  be  such  that  it  cannot  fail  undetected,  even 
though  individual  modules  within  the  stage  may  fail  with  coverage  less  than 
1.  In  other  cases,  stage  failure  may  be  detected  only  by  multiple  module 
failures  being  detected. 

It  should  also  be  noted  that  the  sum  of  transition  rates  out  of  State 
1  is  2f.  In  general,  if  any  state  corresponds  to  N  modules  working,  the 
sun  of  transition  rates  out  of  that  state  will  be  Nf. 

It  should  be  noted  also  that  stages  can  fail  for  two  reasons,  spares 
exhaustion  or  coverage  failure.  In  contemporary  aircraft  systems  having 
critical  functions  to  perform,  coverage  failures  are  of  as  much  concern  as 
spares  exhaustion. 

In  the  previous  dual  stage  example  with  971  coverage  of  the  first 
module  failure,  no  consideration  was  included  of  the  failure  rate  of  the 
monitor  itself.  The  coverage  factor  of  97%  means  that  971  of  the  module 
faults  are  of  such  a  nature  that  they  can  be  detected  by  an  unfalled 
monitor.  The  rest  are  outside  of  the  monitors  capability.  In  cases  where 
dedicated  hardware  monitors  are  used,  it  is  appropriate  to  consider  their 
failure  rates  and  failure  modes.  A  two-state  monitor  is  the  type  most 
frequently  encountered.  It  provides  only  a  GOOD/BAD  signal.  Such  a 
monitor  has  only  two  failure  states:  false  indication  of  BAD  when  the 
module  is  good,  and  false  indication  of  GOOD  when  the  module  is  bad. 

The  simplest  way  of  treating  such  monitors  in  CARSRA  is  to  combine  the 
monitors  with  the  modules  as  a  single  stage.  The  transition  rate  from 
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State  1  to  State  2  La  then  2fcr  ♦  2f  a,  where  f  and  c  are  as  before,  r  is 

re  m  re 

the  reliability  of  the  monitor  over  the  entire  flight  tine,  f  is  the 

monitor  failure  rate,  and  a  is  the  fraction  of  monitor  failures  resulting 

in  a  good  module  being  declared  bad.  The  other  transition  rates  would  be 

similarly  defined,  recognizing  the  relation  between  detection  of  stage 

failure  and  component  monitors.  Each  instance  of  such  a  stage  must  be 

evaluated  individually  in  determining  the  applicable  rate  formules. 

Frequently,  certain  terms  in  a  rate  equation  can  be  ignored  because 

-6 

they  are  numerically  negligible.  For  example,  if  f  s  120  x  10  and  f  » 

—6  * 
0.1  x  10  ,  the  term  2f  a  can  be  ignored  in  the  formula 

re 

f12  *  2fcrm  ♦  2V’ 

provided  c  is  not  absurdly  small.  If  c  is  90%,  a  is  50%,  and  the  flight 
time  is  10  hours, 

f 12  a  2(120  x  10“6)(.90)  exp(-. 1  x  10"6  x  10) 

♦2( . 1  x  10"®) ( .50) 

3  216  x  10"®  ♦  .1  x  10"®. 

Inclusion  of  the  term  yields  a  rate  of  216.1;  Ignoring  it  yields  216. 
The  difference  is  much  less  than  that  caused  by  uncertainty  in  the  module 
failure  rate,  120  x  10"®. 

Dependencies 

CARSRA  permits  the  user  to  desaribe  instances  in  which  failures  of  a 
module  in  one  stage  will  prevent  a  module  in  another  stage  from  being  used. 
An  example  of  this  in  the  RDFCS  is  the  portion  of  eaoh  FCC  channel  whloh 
receives  sensor  data  and  makes  it  available  to  the  other  channels.  Date 
Acquisition  Card  A26  in  FCC  No.  1  receives  data  from  the  No.  1  unit  of  each 
triple  sensor  type,  and  relays  it  to  another  oard  for  transmission  to  the 
other  three  channels  and  for  use  by  its  own  ohannel.  (Ref.  V»l.  IX, 
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Section  5. 1. 1. 3. 1.5) .  There  are  5  triple-sensor  types  involved  in  the 
autoland  mode:  pitch,  roll,  and  yaw  rate  gyros;  and  lateral  and  normal 
accelerometers.  (The  A26  card  also  handles  data  from  other  sensors,  but 
only  these  five  will  be  used  for  discussion  here.)  If  the  A26  card  fails 
in  FCC  No.  1,  the  data  will  be  lost  from  pitch  gyro  No.  1,  roll  gyro  No.  1, 
yaw  rate  gyro  No.  1,  lateral  accelerometer  No.  1,  and  normal  accelerometer 
No.  1,  just  as  if  all  5  of  these  sensors  had  failed.  The  A26  card  is 
called  a  dependency  module,  and  its  stage  a  dependency  stage.  Each  of  the 
affected  sensors  is  called  a  non-dependency  module,  and  the  corresponding 
stage  a  non-dependency  stage. 

Coverage  for  sensor  failures  is  provided  by  comparison  monitoring  and 
reconfiguration  (Vol.  II,  Sec.  5. 1.2.4).  Each  channel  independently  per¬ 
forms  the  sensor  monitoring  functions  on  the  data  it  will  use  in  control 
law  computations.  When  a  channel  detects  a  failed  sensor,  it  does  not 
tranmit  the  identity  of  the  individual  sensor  to  the  other  channels.  When 
a  B  channel  detects  a  failure,  it  does  transmit  a  discrete  variable, 
AP.ONEFAIL,  to  the  A  channel  in  the  same  FCC.  The  A  channel  will  turn  on 
the  NO  DUAL  annunciation  based  on  its  receipt  of  AP.ONEFAIL  from  B,  or  its 
own  detection  of  a  sensor  failure.  The  NO  DUAL  indication  is  provided  to 
inform  the  crew  that  the  RDFCS  is  not  fail-operational.  The  No.  1  FCC 
drives  the  No.  1  Warning  Annunciator  Indicator  (WAI)  and  the  No.  2  FCC 
drives  the  No.  2  WAI,  so  that  warning  will  be  provided  if  either  channel  of 
either  FCC  detects  the  failure. 

The  sensor  monitoring  is  part  of  the  foreground  flight  software.  Con¬ 
sequently,  for  a  channel  to  detect  a  fault,  the  CAPS  processor  must  func¬ 
tion,  as  must  the  CAPS  bus  and  portions  of  the  program  and  data  memory. 
These  are  the  same  hardware  elements  which  perform  other  functions,  such  as 
control  law  computations  and  mode  logic  computatlton.  Most  faults  in  these 
circuit  will  result  in  a  totally  debilitated  processor,  so  that  the  in¬ 
ability  to  the  monitor  sensors  is  Inconsequential.  Notv.  also  that  even  if 
one  channel  does  lose  the  ability  to  monitor  sensors,  any  one  of  the  other 
three  channels  can  force  the  NO  DUAL  warning. 

In  light  of  the  foregoing,  the  only  appreciable  probability  that  the 
loss  of  fail-operational  sensor  capability  will  not  be  annunoiated  results 
from  loss  of  both  WAI.  The  multiple-function  WAI  (Ref.  Vol.  II,  Section 
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5.16.1)  has  a  unit  failure  rate  prediction  of  33  per  million  hours.  The 
failure  rate  of  any  one  of  the  8  warning  messages  is  conservatively  taken 
to  be  one-fourth  the  unit  rate,  or  8.3  per  million.  It  may  be  noted  from 
Vol.  II,  Table  5. 1.4.6  that  the  FCC  activates  the  NO  DUAL  message  by  pro¬ 
viding  a  ground  to  the  WAI,  so  that  a  broken  wire  or  bad  connector  contact 
would  prevent  annunciation.  A  rate  of  1.3  per  million  hours  is  included 
for  suoh  failures.  Also,  the  Discrete  Output  (A20)  and  Servo  Engage  Logic 
(A28)  cards  are  involved,  tilth  failure  rates  of  2.79  and  2.61  per  million 
hours,  respectively.  Even  though  only  a  portion  of  the  failures  of  these 
cards  will  affect  NO  DUAL,  the  full  rate  is  used.  Further  analysis  could 
reduce  this  rate  substantially,  The  failure  rate  for  NO  DUAL  is  then 

WAI  8.3  x  10"6 

Wiring  1.3 

A20  Card  2.79 

A28  Card  2.61 

15.0  x  10~6 

The  probability  of  failure  in  a  4-hour  time  period  is  then  60  x  10“^.  The 
Probability  of  both  NO  DUAL  warnings  being  lost  is  the  square  of  this 

_Q 

number,  3.6  x  10  .  It  may  be  noted  from  Vol.  II,  Sec.  5. 1.2. 3. 1. 1.3  that 

the  test  button  on  the  WAI  results  in  the  FCC  circuitry  and  the  wiring 
being  tested  as  well  as  the  WAI  itself.  Thus  latent  failures  are  not  a 
problem,  provided  the  indicators  are  tested  prior  to  autoland. 

The  factor  3.6  x  10”®  la  used  as  the  probability  that  the  first 
failure  of  a  sensor  type  will  not  be  covered.  This  does  not  constitute 
stage  failure,  either  detected  or  undetected.  Undetected  stage  failure  is 
assumed  to  occur  on  second  failure,  provided  the  first  failure  was  un¬ 
detected.  This  is  somewhat  a  misuse  of  the  term  "undetected”;  the  stage 
failure  Itself  is  not  necessarily  undetected,  but  the  increased  likelihood 
of  its  occurrence,  following  first  failure,  is  not  annunciated. 

This  treatment  of  sensor  failures  allows  the  availability  feature  of 
CARSRA  to  be  used  in  computing  the  probability  of  loss  of  one  sensor  prior 
to  150  ft.,  failure  of  the  NO  DUAL  annunciation,  and  another  failure  below 
150  ft.  The  aallablllty  feature  is  dlsoussed  in  the  next  seotlon. 


CARSRA  permits  system  reliability  to  be  computed  for  a  mission  phase 
which  follows  a  period  of  operation  with  less  stringent  failure  criteria. 
An  obvious  example  of  this  is  the  RDFCS,  which  is  fail-passive  in  cruise, 
but  must  be  fail-operational  in  autoland  below  150  ft.  The  availability 
feature  allows  the  user  to  specify  which  modules  may  be  failed  at  the 
beginning  of  autoland  without  forcing  diversion  to  an  alternate  landing 
site.  Each  such  availability  configuration  must  provide  adequate  re¬ 
liability  for  the  landing,  although  not  as  much  as  if  everything  is  work¬ 
ing.  The  RDFCS  requires  all  of  the  modules  used  in  autoland  to  be  oper¬ 
ational,  so  that  the  availability  feature  might  seem  not  needed  in  this 
assessment.  It  is  needed,  though,  to  compensate  for  a  capability  which 
CARSRA  lacks. 

The  reliability  of  the  RDFCS  for  automatic  landing  is  predicated  on 
the  system  being  fall-operational  as  the  alert  height  is  passed.  There¬ 
fore,  the  probability  of  the  system  having  a  latent  failure  at  150  ft.  and 
a  second  failure  below  that  point  must  be  quite  small. 

By  setting  up  the  CARSRA  input  to  allow  one  sensor  of  each  type  to 

fail  during  cruise,  with  the  transition  rate  from  State  2  to  the  undetected 

_o 

failure  state  including  the  coverage  factor  of  3.6  x  10  ,  the  undetected 

system  failure  probability  computed  by  CARSRA  will  give  the  probability  of 
an  undetected  latent  failure  at  150  ft.  and  a  second  failure  before  touch¬ 
down.  (See  Figure  27) 

What  CARSRA  will  actually  compute  is: 

P(0  failures  at  4  hours)  x  P( undetected  failure 
and  detected  failure  between  4  and  4.02  hrs.) 

♦P(1  undetected  failure  at  4  hours) 

x  P  (second  failure  between  4  and  4.02  hrs.) 

Since  the  probability  of  both  an  undetected  and  a  detected  failure 
between  4  and  4.02  hours  is  very  small,  the  first  term  is  negligible  and 
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DUAL  SENSOR  TRIPLE  SENSOR 

fl2  2f  3T 

f13  0  0 

f14  0  0 

f23  '  * 

f24  To  2fb 

f  -  MODULE  FAILURE  RATE 
o  *  ANNUNCIATION  FACTOR  3.6  «  Uf9 


Figure  27  .  Markov  Modal  Coding  far  Samar  Stagat 


the  output  will  be  equal  to  the  second  term,  which  is  the  probability 
desired,  This  approach  is  used  for  the  undetected  (unannunciated)  failures 
throughout  the  system.  The  definition  of  stages  and  the  transition  rates 
are  shown  in  Figure  28. 

The  CARSRA  program  computed  some  negative  probabilities  for  the  un¬ 
annunciated  failures.  It  is  suspected  that  this  may  have  been  caused  by 
the  program  being  run  on  a  Univac  1100-series  computer,  which  has  a  36-bit 

word  length.  The  transition  rates  to  the  unannunciated  failure  states  are 

-1 3 

quite  small  in  some  cases  (1  x  10  ),  and  addition  and  subtraction  of 
numbers  of  this  magnitude  with  numbers  close  to  1.0  could  produce  some 
numerical  accuracy  problems  on  a  36-bit  machine.  At  NASA-Ames,  the  program 
is  run  on  a  CDC  computer,  which  has  a  much  larger  word  size,  64  bits,  so 
that  the  problem  is  thought  to  be  unlikely  there.  Time  was  not  available 
during  the  study  to  investigate  and  resolve  the  problem,  but  this  will  be 
done  when  possible. 

Because  of  the  numerical  problem  encountered  with  the  CARSRA  output, 
the  system  failure  probabilities  reported  herein  were  actually  manually 
calculated.  This  was  done  by  manually  computing  the  stage  occupancy 
probabilities,  and  then  combining  these  probabilities  to  account  for 
dependencies  between  stages,  using  the  same  logic  that  the  CARSRA  program 
uses. 

The  probability  of  an  undetected  failure  prior  to  the  crucial  phase, 

followed  by  a  second  failure  in  the  crucial  phase,  is  3-36  x  10”1**, 

-1 4 

compared  to  2.46  x  10  from  the  fault  trees.  The  probability  of  multiple 
failures  in  the  crucial  phase,  if  everything  is  working  Just  prior  to  the 
phase,  is  0.658  i  10  compared  with  0.638  x  10  from  the  fault  trees. 
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FIGURE  28.  CARSKA  INPUT  (Cont’d) 
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The  conclusions  resulting  from  this  study  relate  to  the  benefits  and 
limitations  of  the  integrated  assurance  approach  used  and  the  RDFCS  Simula¬ 
tor.  Certain  of  the  conclusions  lead  to  recommendations,  as  discussed  sub¬ 
sequently. 

The  primary  conclusion  drawn  from  this  study  is  that  the  integrated 
assurance  approach  used  is  workable  for  a  system,  such  as  the  RDFCS,  which 
employs  monitoring  totally  separate  from  the  hardware/ software  being 
monitored.  In  the  RDFCS,  this  monitoring  includes  the  servo  coil  current 
comparators  and  the  modulator  piston  follow-up  monitoring.  It  also 
Includes  the  warning  annunciations  which  one  FCC  can  generate  following  a 
failure  in  the  other  FCC.  A  single-string,  self-monitored  system  might  be 
much  less  amenable  to  this  approach,  depending  on  the  monitoring  approaches 
used.  This  possibility  is  outside  the  scope  of  this  study. 

Fault  tree  analysis  is  a  feasible  analytical  method  for  system  level 
faults.  One  benefit  is  that  specific  software  failures  are  identified  as 
the  analysis  progresses.  These  can  be,  and  should  be,  used  as  a  check  on 
the  validation  test  case  selection  to  assure  that  the  software  function  is 
rigorously  tested.  Fault  trees  can  be  extended  to  the  circuit  card  level 
in  a  well  organized  computer  such  as  used  in  the  RDFCS.  In  general,  the 
analysis  is  facilitated  by  a  design  with  clearly  partitioned  and  identifi¬ 
able  functions  and  interface  structure  which  is  consistent  for  all  card 
Inputs  and  outputs. 

Failure  mode  and  effect  analysis  is  more  easily  accomplished  than 
fault  trees  within  the  processor  itself.  This  is  because  of  the  processor 
being  Involved  in  a  diverse  set  of  functions  defined  by  the  flight 
software.  Host  individual  pin-level  faults  have  many  effects.  Usually, 
each  fault  can  be  traced  to  an  effect  which  totally  debilitates  the 
processor.  Other  effects  which  would  also  cause  massive  prooesaor  failure, 
or  erroneous  results  only  under  certain  conditions  do  not  have  to  be 
analyzed  in  detail,  provided  their  effects  will  not  propagate  across 
channels.  In  contrast,  a  fault  tree  analysis  based  on  loss  of  required 
system  functions  would  result  in  identification  of  the  same  hardware  faults 
time  after  time. 


The  FMEA  and  fault  insertion  sessions  should  be  on  an  iterative  basis. 
After  beginning  the  FMEA,  a  fault  insertion  session  should  be  used  to 
confirm  the  analysis  to  that  point.  The  results  should  then  be  incorpor¬ 
ated  in  the  FMEA  and  the  entire  FMEA  reviewed  in  light  of  those  results. 
This  review  may  lead  to  identification  of  additional  fault  cases  which 
should  be  simulated  to  resolve  uncertainty  which  may  have  arisen.  This 
iterative  approach  was  not  feasible  in  this  study  because  of  limitations  on 
the  availability  of  the  simulator,  which  was  being  used  on  other  projects. 

The  RDFCS  simulator  has  substantial  capability  for  research  investiga¬ 
tions  of  digital  flight  control  system  validation  issues.  This  capability 
would  be  significantly  Improved  by  an  automated  fault  insertion  and  data 
recording  capability.  Such  a  capability  should  be  preprograomable  with  a 
list  of  faults  to  be  Inserted.  It  should  include  means  of  recording  the 
impact  of  each  fault  (e.g.,  changes  in  the  values  of  discrete  variables) 
for  many  more  variables  than  the  4  accessible  through  the  CTA's.  It  should 
allow  variables  in  channels  other  than  the  faulted  one  to  be  accessed  and 
recorded . 

CARSRA,  in  its  present  form,  should  be  used  with  caution  when  small 
failure  rates  are  Involved  and  when  execution  is  to  be  on  a  computer  with  a 
shorter  word  length  than  the  64  bits  used  in  Control  Data  computers.  The 
possibility  of  erroneous  system  failure  probability  values  being  output 
exists  under  such  conditions.  This  needs  to  be  explored  further. 

Fault  tree  analysis  and  CARSRA  provide  comparable  results  for  rela¬ 
tively  straightforward  redundancy  conditions,  such  as  the  probability  of 
multiple  failures  during  the  crucial  phase  when  all  components  are  working 
at  the  beginning  of  the  phase.  For  more  complicated  situations,  the  two 
methods  do  not  agree  as  closely.  This  is  a  result  of  different  simplifica¬ 
tions  and  assumptions  being  made  to  structure  the  problem  to  the  two 
methods.  For  example,  the  third  sensor  of  a  triple  sensor  set  (Figure  1) 
has  redundant  input  paths  to  the  computers  (the  data  input  seotiona  of  the 
two  computer  B  channels)  but  the  other  sensors  have  only  a  single  data  path 
(the  A  channel  input  sections).  This  is  treated  correotly  in  the  fault 
trees,  but  the  redundancy  cannot  be  accounted  for  in  CARSRA.  The  conserva¬ 
tive  assumption  is  therefore  made  that  loss  of  either  B  channel  senaor 
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input  capability  will  cause  loss  of  the  third  sensor  in  all  triple  sensor 
sets.  In  validation  work,  any  assumptions  required  can  be  made  conserva¬ 
tively  so  that  the  computed  failure  probability  is  actually  an  upper  bound 
on  the  true  probability. 
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APPENDIX  A.  FMEA  RESULTS 
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APPEMDIX  C.  PROCESSOR  SCHEMATIC  DIAGRAMS 
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FIGURE  C-l.  CONTROL  CARD  SCHHMATIC  DIAC 


FIGURE  02.  DATA  PATH  CARO  SCHEMATIC  DIAGRAM  (SHEET  3  of  3) 


